\section{3. Patterns 1: GoF Strategy + GoF Template Method}

\begin{center}
\line(1,0){500}
\end{center}

\begin{itemize}
\item Redegør for, hvad et software design pattern er.
\item Sammenlign de to design patterns GoF Strategy og GoF Template Method – hvornår vil du anvende hvilket, og hvorfor?
\item Vis et designeksempel på anvendelsen af GoF Strategy
\item Redegør for, hvordan anvendelsen af GoF Template fremmer godt SW design
\item Redegør for, hvilke(t) SOLID-princip(per) du mener anvendelsen af GoF Strategy understøtter 	
\end{itemize}
\begin{center}
\line(1,0){500}
\end{center}

\subsubsection{Hvad er et pattern}
\begin{itemize}
    \item Et løsnings-forslag til et almindeligt opstående problem
    \item En template
    \item En form for formel "best practice"
\end{itemize}
\subsubsection{Strategy vs Template, hvor og hvorfor}
\begin{itemize}
\item Begge er behavioural mønstre
\item Benyttes til at gøre opførslen af et system udvidelses venlig
	%Template
    \item \textbf{Template benytter inheritance}
    \begin{itemize}
        \item Basisklassen er template(abstract), specialiseringen er implementationen\\
        \includegraphics[scale=1]{3-bubblesort}
        \item Bryder delvist DIP
         \begin{itemize}
              \item outOfOrder og Swap er afhængig af implementationen af bubblesort
          \end{itemize} 
          \item Mindre fleksibel af de to
          \item Simplere og nemmere at implementere
          \item Ofte benyttet i frameworks
          \begin{itemize}
              \item Frameworket implementere den abstracte klasse
          \end{itemize}
    \end{itemize}    
    %Strategy
    \item \textbf{Strategy benytter delegation}
    \begin{itemize}
        \item Uddeler ansvaret for f.eks. en algoritme til strategien\\ 
        \includegraphics[scale=1]{3-strategy}
        \item Benyttes til at fjerne behavior fra klienten
        \item Nemt at tilføje ny behavior
        \item Giver lavere kobling
        \item Understøtter OCP og DIP
        \begin{itemize}
            \item OCP: Det er ikke nødvendigt at "åbne" klienten for at ændre funktionalitet
            \item DIP: Klienten er ikke afhængig af den konkrete implementation
        \end{itemize}
        \item Kræver at der bliver implementeret en ekstra klasse
    \end{itemize}
\end{itemize}
\subsubsection{Eksempel}
\subsubsection{Godt SW Design}
\subsubsection{Hvilke SOLID-principper understøttes}
\begin{itemize}
    \item \textbf{Template}
    \begin{itemize}
    	\item SRP fremmes - Klienten skal ikke implementere templaten        
        \item Overholder OCP
        \item LSP fremmes - Afledte klasser skal overholde LSP for at metoden virker efter hensigten
        \item Overholder delvist ISP - der benyttes en abstract klasse / interface   
        \item Bryder delvist DIP
    \end{itemize}
    \item \textbf{Strategy}
    \begin{itemize}        
        \item SRP fremmes
        \item Overholder OCP
        \item LSP fremmes
        \item Overholder ISP        
        \item Overholder DIP
    \end{itemize}	
\end{itemize}